COMMENT ⊗   VALID 00010 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	outline
C00004 00003	data objects
C00007 00004	language constructs
C00008 00005	prog env.
C00009 00006	implementation issues
C00010 00007	modern issues
C00011 00008	general issues:
C00012 00009	faults in lisp
C00013 00010	what we won't see at the conference
C00014 ENDMK
C⊗;
outline
morning
	9-10:15   intro, history
	10:30-12  modern issues, papers

afternoon
	1:30-3:15 video tapes
	3:30-5:00 discussion sessions


intro to "modern" lisp

alan kay's remark

history of implementations and features they introduced

704 (1.5) → 7090 → 7040     gc, funarg, etc

pdp-1 → sds940 → bbn-lisp → interlisp

pdp-6 maclisp (value cell) → 1.6 → uci (1.6+bbn editor) → yale
			   → bibop maclisp → lm lisp (mac+ mdl)

						→ NIL
						→ Franz lisp

vlisp(10,11,80)

standard lisp

lisp370

wisconsin/maryland lisp

micro lisps

aside: list of available implementations and origin

----------
lisp-ish languages  and features

planner		pdi and related benefits (see prolog)
conniver	context layers (see PIE), a "machine" (see Scheme chip)
muddle		&-syntax; algolish syntax, multiprocessing
ecl		more algolish, extensibility, data type delcarations
scheme		lexical scoping. "chip-able"
smalltalk(?)	object-oriented, classes, windows in env.

data objects
	lists
	   the traditional lisp data structure. everything is a pointer
		and therefore instead of saying "x is a pointer to a foo",
		we need only say "x is a foo". incredible liberation.

	symbols
	   aka literal atoms: pointers must stop somewhere, and in lisp these
		symbols are the primitive objects for representation (naming)
	
	numbers
	   the traditional primitve object in traditional prog. langs.
	 arb. prec.
	    an improvement in lisp's arithmetic (c. 1968) numbers as lists

	arrays
	   the "structured object" in primitive languages
		in lisp, just another tool for data.  key: first-class, but
		many lisp's  slip up here

	strings
	   another ....

	p-lists 
	   to some extent lisp's "record structure", but much more flexible 
		as basis for simple obj-or. programming. (leads into ...)

	functions **
	   yes, functions are data items in lisp: very important. source of much
		current controversy.


	envrionments (as data)  NB this is not what is meant by "prog env"
	   interesting innovation based on soln to function as data: the symbol
		table defining the environment is available as manipulatable
		data.  it is a tree-struture (non-stack) therefore in 1.5 defn
		was a gc-ible commodity.

	control (as data)
	   differs from above: run-time computational history is open to 
		investigation and m→nipulation.	cf. debugging
		this is a freer interpretation than most lisps allow



	hunks (?)

language constructs
	syntactic issues: prog as data
		progs are rep as list structure. 
		  why and when
			jmc and turing machine
		  why it is good
			ediiting,debugging, compiling, ... i.e. prog manipuation
			side-step uninteresting syntax questions. semanitcs lang.

	control: modulo syntax, traditonal
	 do
	 if
	 <=
	function
	catch/throw
	macros
	read macros

prog env.
	interactive language
	    read-eval-print of machine
	windows ala smalltalk and LM


implementation issues
	address space
	  big!

	 typing of data, not identifiers
	  strong type vs. type free
	 tags

	 bibop   (tlc-lisp)
	  why
	  why not

	gc
	 why: cf ref count
	 how:	mark-sweep
	 	compact
	 	real-tiime
	 	multi-process

	shallow/deep binding
	 trade-offs
	 baker(?)

modern issues
	abstract programming
	    construct, select, recog

	object oriented

	funargs

	scoping: lexical/fluid  aka static/dynamic

	prog as data

general issues:
	why lisp for ai
	 lists as rep of iq data
	 flex prog env in exploratory programming

	why lisp for cs

	prop envs.
	sil

faults in lisp
	parallelism
	message passing/object oriented
	fsubrs


what we won't see at the conference

	how to impl lisp on my (least)favorite machine

	AI applications

	programming applications

what we will see at conference

	multi processing

	impl on interesting hardware (NB ¬mit lm ¬→ ¬interesting!)

	general architecture/impl questions

	prog env (fhl and henry)

	non-ai applications

	theory